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(54) Database network 

(57) A method and apparatus for publishing and 
receiving events to a network (120). A plurality of "pub- 
lisher** entities publish information and a plurality of 
"subscriber" entities request and use the information. 
Publishers (102, 110, 116) and subscribers (104. 112. 
118) are connected to each other through a network 
(120). The network (120) Is a "store and fonward" net- 
work whose routing is "content-based." The t>asic 
quanta of information Is called an "event" Publishers 
(102. 110, 116) put)lishs events and subscribers (104. 
112, 118) sub5crit>e to events that match criteria 
defined by tiie subscriber (104, 112. 118). Publication 
and subscrption are performed asynchronously. Pub- 
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lishers (102. 110. 116) and subscribers (104. 112. 118) 
do not have direct knowledge of each other. The system 
(100) receives a published event from a publisher (102, 
110, 116) and routes the event to all appropriate sub- 
scribers (104. 112, 118). Each subscriber (104, 112, 
118) is guaranteed to receive all events published on 
tiie system (100) if. and only if, they match the sut)scrip- 
tion criteria specified by tiie sut>scriber. A legacy data 
base can t>e added to the network by way of a data base 
connector, which can be a publisher, a sut3scriber. or 
both. 
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Description 
Appendices 

5 Appendix A. which is a part of this specification and is herein incorporated by reference, contains a summary of 
exemplary system events that can be passed between hubs in a preferred embodiment of the present 

Background of the Invention 

10 This application relates to an information publishing system and, more particularly, to a method and apparatus for 
connecting a legacy data base to an information publishing system. 

Certain conventional systems use a "transactional" model for exchanging information between nodes of data 
processing system. In a conventional transactional nxxJel, two applications initiate a synchronous "transaction" that is 
maintained for as long as information is being exchanged between the nodes. The transactional model requires that a 

15 transaction be defined for each business activity. When nodes on widely disparate portions of a network attempt to com- 
municate via tiie transaction model, it is often difficult to define a transaction that works well on all parts of the system. 
Moreover, a transaction can only involve the nodes that began the transaction. Another node cannot join the ti^ansaction 
in tiie middle. This scheme is unsurted for a system in which nodes do not know about all other nodes in tiie system. 
Many commercial enterprises still use software that was developed long ago and is no longer supported by its man- 

20 uiacturer. Such software is called "legacy software." In addition, many commercial enterprises use commercial software 
products. It is not always possible or desirable to modify existing commercial software and legacy software to operate 
witti a new networked system. The commercial software and legacy software riiay be very complex, making it difficult 
and expensive to modify. A company may be wary of making modifications to a stable system that is working consist- 
entiy. Moreover, there may not be any computer programmers at a company who understand the legacy system in 

25 enough detail that they can make modifications to it. Lastly, a company may not have the source code for a legacy appli- 
cation if it purchased the application from a commercial vendor. A company also may not have a legal right to modify 
commerdal data base software. What is needed is a way to integrate commercial and legacy data base software into a 
networked system without having to modify the data base software itself. 

30 Summary of the Invention 

The present invention overcomes the problems and disadvantages of the prior art by providing a "data base con- 
nector" element that can act as either a publisher or a sut>scriber in the network. 

The present invention is implemented as a type of "middleware." Middleware is software that is located between an 

35 application program and a control-level program. Middleware is "network centric" and does not concentrate on a spe- 
cific user interface or on the organization of a specific database. The described embodiment includes a plurality of "puth 
lisher" entities, who publish information, and a plurality of "subscriber" entities, who request and use tiie information. 
Publishers and subscribers are connected to each otiier ttirough a network The network is a "store and iovntardr net- 
work whose routing is "content-based." In a content-based routing system, information is routed based on the content 

40 of tiie information, and not on the addresses of publishers or subscribers in the system. In the described emtxxliment, 
information is distritxjted to many subscribers in parallel. 

In the described embodiment, tiie basic quanta of information is called an "event" Publishers publish events and 
subscribers subscribe to events that match criteria defined by tiie subscriber. In tiie desaibed embodiment, events are 
represented by data structures in ttie C programming language, although any appropriate representation can be used. 

45 Publication and subscription are performed asynchronously. Publishers and subscribers do not have direct knowl- 
edge of each otiier. The system receives published event from a publisher and routes the event to all appropriate sub- 
scribers. Each subscriber is guaranteed to receive all events put)Iished on the systenri if. and only if. tiiey match the 
sut)scription criteria specified by the subscriber. 

The described embodiment includes an Application Programming Interface (API) for publishers and for subscrib- 

50 ers. The API defines a plurality of procedures that allow respective publishers and sut>scribers to interface to the sys- 
tem. Thus, various types of publishers and subscribers can be connected to the system, as long as ttiey use the 
interface procedures defined in accordance with the API. The described embodiment also includes support for a plural- 
ity of software elements such as common databases, installation and administration tools, and logging facilities. Thus, 
ttie described embodiment is termed an "enterprise system" because it can be used throughout tiie entirely of a com- 

55 mercial enterprise. 

The described embodiment of the present invention makes it easy to integrat legacy systems, legacy applications, 
and legacy hardware into tii system and attempts to minimiz tiie amount of information that a user must learn to use 
tiie system. Because communication witiiin tiie system is based on asynchronous "events." the present invention can 
be implemented on a heterogeneous network tiiat includes both PCs and mainframes executing under various operat- 



2 



EP0 806 731 A2 

ing systems and running various types of applications. The described embodiment utilizes a distributed-objecl environ- 
ment and a preferred embodiment of the present invention implements the Common Object Request Broker (CORBA) 
standard. 

In accordance with the purpose of the invention, as embodied and broadly descrft)ed h r in, th Invention relates 
5 to a method of connecting a data base to a publisher/subscriber n tworK so that the data base can publish events to 
the network, the method comprising the steps, performed by the data processing system, of: providing a link so that the 
data base can communicate with a data base connector conrputer program by way of a transaction monitor computer 
program; setting up the data base connector as a publisher hub in the network; receiving Input, by the data base, from 
a user that alters data in the data base; informing the transaction monitor that the data has been altered; receiving input 
10 from the user indicating that the altered data should be committed; informing the transaction monitor that the altered 
data is committed; and sending, by the data base connector, in accordance with a message from the transaction mon- 
itor that the data is committed, a published event to the network in accordance with the altered data. 

Objects and advantages of the Invention will be set forth in part in the descriptfon which follows and In part will be 
obvious from the description or may be learned by practice of the invention. The objects and advantages of the inven- 
ts tion will be realized and attained by means of the elements and combinations particularly pointed out in the appended 
claims and equivalents. 

Brief Description of the Drawings 

20 The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several 
embodiments of the invention and, together with the description, serve to explain the principles of the invention. 

Fig. 1 is a block diagram of a networked computer system in accordance with a prefen-ed embodiment of the 
present Invention. 

Fig. 2 is a flow chart showing steps performed to install an application, such as a publisher, on a hub of Fig. 1. 
25 Fig. 3 Is a flow chart showing steps performed by a publisher of Rg. 1 to publish events. 

Fig. 4 Is a flow chart showing steps performed by a subscriber of Rg. 1 to subscribe to events. 
Fig. 5 is a block diagram showing details of a hub of Rg. 1 . 

Fig. 6(a) is a diagram showing data structures stored in a memory of the hub of Rg. 5. 
Fig. 6(b) is a listing of details of the data structures of Fig. 6(a). 
30 Fig. 7 is a diagram of additional data structures stored in the memory of the hub of Rg. 5 for the purpose of storing 
Information atx)ut clients of the hub. 

Fig. 8 shows a format of an envelope data structure of an event. 
Rg. 9 shows a format of a routing block of an event 

Fig. 10 is a flow chart showing details of steps performed by tiie hubs of Rg. 1 to populate the data structures of 

36 Fig. 6(a). 

Fig. 11 is a diagram showing exanrples of tiie data structures of Fig. 6(a) populated witii data. 
Fig. 12 is a flow chart showing details of steps performed by the hubs of Fig. 1 to send published events to sub- 
scrtoers. 

Fig. 1 3 Is a block diagram of a data base application Incorporated into the network of Rg. 1 . 
40 Fig. 1 4 is a flow chart showing steps performed when tiie data base is a subscriber. 
Fig. 15 is a ffow chart showing steps performed when tiie data base is a publisher 

Detailed Description of the Preferred Embodiments 

46 Reference will now be made in detail to tiie preferred embodiments of the invention, examples of wtuch are illus- 
trated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout tiie 
drawings to refer to the same or like parts. 

I. Overview 

50 

Fig. 1 Is a block diagram of a networked computer system 100 in accordance with a preferred embodiment of ttie 
present invention. Nietworked computer system 100 includes a plurality of publishers 102, 110. and 116 and a plurality 
of subscribers 104. 1 12. and 1 18. Publisher 102 and subscriber 104 are connected to a network 120 through a hub 106. 
Publisher 1 10 and subscriber 1 12 are connected to network 120 tiirough a hub 108. Publisher 1 16 and subscriber 118 
55 are connected to network 120 through a hub 1 14. Hub 1 06 and its connected publishers and subscribers ar in a first 
ten-itory 130. Hubs 108 and 114 and their connected publishers and subsaibers ar in a second territory 140. Other 
territories (not shown) also exist in network 120. "Hubs." "publishers." "subscribers," and "territories" are discussed 
below in turn. 

As indicated by dotted lines in Rg. 1 , each publisher, subscriber, and hub can be located in separate computers 
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( 102, 1 04, and 1 06), in the sam computer (1 08, 1 1 0. and 11 2) or in some combination of separate computers and the 
same computer (114, 116. and 1 18). Hubs can have zero or more publishers and zero or more subscribers. Hubs can 
also be directly connected to other hubs. 

It will be understood by persons of ordinary skill in the art that each computer (represented in Fig, 1 by dotted tin s) 

5 includes a CPU. a memory, and input/output lines. These elements are not shown in th figure for the sake of clarity of 
example. Each computer can also include numerous other elements, such as disk drives, keyboards, display devices, 
network connections, additional memory, additional CPUs. etc. The publishers, subsaibers. and hubs preferably are 
implemented as software instructions stored in a memory and executed by a processor of a computer system. Usually, 
the publisher, subscriber, and hub software is executed by a processor of the computer in which the software is stored. 

10 although a processor of another computer system could also execute the software. 

A prefen-ed embodiment of the invention runs under the Solaris operating system. Version 2.4. Solaris is a trade- 
mark of a registered trademark of Sun Microsystems. Inc. in the United States and otiier countries and is based on tiie 
Unix operating system. Unix is a registered trademark in the United States and other countries, exclusively licensed 
through X/OPEN, Lid. Networked computer system 100 uses a network communication protocol, such as TCP/IP, 

75 although any appropriate protocol can be used to implement the present invention 

In the described embodiment, a "publisher" publishes events of certain types on the network 120 and a "subscriber" 
subscribes to events of certain types. The publisher and subscriber operate asynchronously and are unaware of each 
other's existence. Use of a "publish and subscribe" model insulates applications from the network and from each other. 
Publishing can be thought of as broadcasting an event. The event type is analogous to a radio station. Applications 

20 interested in a particular station subscribe (or tune in to) a specific event type. Just as in radio broadcasting, where all 
parties involved must agree in advance on a set of possit>le frequencies, applications in the descnl^ed embodiment 
must agree in advance on a predetermined set of event types. 

The described embodiment of the present invention uses "subscription by content." Subscribers specify what tiiey 
want based on an event type and on the content of the event. The described emlxxJiment makes use of "store and for- 

25 ward" techniques for events. This term means tiiat the system buffers event, so that, even if a publisher is off-line, a sub- 
scriber can still retrieve events. Similarly, a publisher can publish events even if a subscriber is off-line. 

The described embodiment is managed in units of hubs. A hub, such as hub 106, is a local connection point for a 
publisher and/or a subscriber. Both publishers and subscribers are called "clients" of hubs. A publisher uses an "adver- 
tisement" to tell the system what types of events it intends to publish and how it intends to publish them (e.g., daily as 

30 each event frigger occurs, etc). Advertisements are registered with the hub connected to the publisher during the instal- 
lation of the publisher. An advertisement must have a unique name. In addition to containing a name of an event type 
to be published, an advertisement contains other information about the publisher. This information can include tiie pri- 
ority level for the published events, for how long tiie events are valid, etc. Hubs tiansmit advertisements to all potential 
subscribers. Hubs ti^ansmit published events to all sut)scribers who have subscribed to events of that type, whose con- 

35 tent matches the sufc)scriber's subscription. 

11. Publishers and Subscribers 

The following paragraphs describe the steps required to create an application (either a publisher or a sut>scriber) 

40 and to install it on a hub. The following paragraphs further describe the steps performed by an example publisher to 
publish events and by an example subscriber to subscribe to events. The described embodiment allows a programmer 
to write software for applications (publishers and subscribers) in a high level language and to interface witii the hub 
using routines defined in an API and using event manipulation routines generated for each user-defined event type. 
Fig. 2 is a fbw chart showing steps performed to install an applk;ation, e.g., a publisher, on a hub. Rg. 3 is a flow 

45 chart showing steps performed by an installed publisher to publish an event. Rg. 4 is a flow chart showing steps per- 
formed by a subscriber of Rg. 1 to subscribe to events of a certain type and content. As discussed above, both publish- 
ers and subscribers preferably are implemented as software programs executed by a processor. 

The descrbed embodiment is centered around the sending (publication) and receiving (subscribing) of events. 
Before a publisher can publish events, ttie publisher must define and advertise the events that it will publish. In order for 

50 the events to make sense, publishers and subscribers need to understand each other. For this reason, ttie described 
embodiment uses a standard specification language to define events. In step 202 of Rg. 2, the publisher defines one 
or more events tiiat can be published by that publisher. The described embodiment of the described embodiment allows 
definition of events using an industry standard Interface Definition Language (IDL). IDL is a standard interfece propa- 
gated by the Object Management Group (OMG). although any applicable syntax for describing tiie structure of tiie 

55 event could be used in conjunction witii the described embodiment. In Step 204, the OMG IDL definitions of tiie events 
are ti^anslated into data structures in the C programming languag . 

Assume, for exampi . ttiat an application publishes "SalesOrder" events. Befor tti application could be added to 
the system, and assuming tiiat no other applications dealing witti SalesOrder events already existed, a programmer 
woukJ define a "SalesOrder" event using OMG IDL as folfows: 
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//fflename: ordenddl 

interface SalesOrder { 
struct Address { 

string street; 
string city, 
string state; 
unsigned long zip; 

}; 

attribute string customer_name; 
attribute Address customer^address; 

}; 



The above syntax defines an event as an Interface" and defines tfie data members in tlie event as "attributes." 

After one or more events fiave been defined, the events are translated into structure definitions of the C program- 
ming language. Preferably, this translation is performed by an OMG IDL compiler, which generates a header file and a 
25 code file for each event. The generated header file contains simple C-language structures that represent the event dec- 
larations for the typed functions defined in the code file. The C structure definition generated for the above example 
event of type SalesOrder is: 



^ typedef struct SalesOrder_Address { 

nxsString street; 
nxsString city; 
nxsString state; 
nxsULong zip; 
} SalesOrder_Address; 

typedef struct SalesOrder { 

nxsString customer_name; 
^ SalesOrder_address customer^address; 

} SalesOrder; 



45 A person of ordinary skill in the art will easily understand how the IDL of the example translates into the C programming 
language structure definitions shown above. 

Tlie code file generated from the event definition contains procedures for manipulating events of the defined type 
(here, for the SalesOrder event). The procedures perform at least the following operations: 

50 For use bv a publisher: 

Create event of type SalesOrder, 

Pid>lish event of type SalesOrder, 

55 

Destroy event of typ SalesOrder 
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For use bv a subscriber: 

Print cont nis of event of type SalesOrder, 
Register Subsaiption for event of type SalesOrd r, 

5 

A person of ordinary skill in the art will understand that, although the above plurality of procedures is generated for 
each defined event, the operation of the procedures differ due to the differences in the structures of the event. The pro- 
cedures also differ due to the fact that the described embodiment uses typed function to prevent programming errors. 
The process of installing a process application in a hub includes storing one or more advertisements in the hub, as 

10 shown in step 206. These advertisements define types of events that the hub knows ai30ut An advertisement includes 
the name of the advertisement, a description of the event that a publisher publishes (e.g.. a SalesOrder event), a 
description of how the publisher publishes its events (e.g., daily, when an event trigger occurs, etc.), the name of the 
event type, the priority level of the events, and the expiration time on the events (also called "time-to-live'O. Although not 
shown in the Rgure, the described embodiment also allows access control permissions for the various event types to 

IS be set. 

The described embodiment also includes predefined routines in an API, which are available to the publisher and 
subscriber software and which include routines to perform at least the following functions: 

Register a client, 
20 Reestablish a client with an existing session, 

Unregister a client. 

Registering intent to publish, 

Unregistering a publication. 

Publishing an event. 
25 Subsaibing to an event. 

Reactivating an active subscription to an event and 

Cancelling a subscription, 

Other APIs in accordance with the present invention may include somewhat different API functions. In addition, the 
30 API preferably Includes a "can.subscribe" routine and a "can_j)ubllsh'' routine that return a Boolean value indicating 
whetiier tiie calling application can subscribe to or publish events of a certain type. The API also includes a 
"get_current_envelope" routine that returns information about the publisher of an event and how the event was pub- 
lished. (This routine can only be called from the call-back procedure). A call-back procedure is called. e.g., when a sub- 
scrOber receives an event Fig. 8 shows a format of an envelope data structure for an event, which is discussed below 
35 in connection with event routing. 

It will be understood that when the event description for a publisher or a subscriber is initially translated Into, e.g., 
C. the event header file, whose generation is discussed above, is included witiiin the application software source code. 
Thus, in ttie example, tiie publisher has access to the definition of the SalesOrder event. The translation also links tfie 
event manipulation routines and API routines into the application at this time. The hub, along with other hubs, transmits 
40 a notice of tiie advertisement existence to potential subscribers, as discussed below. 

Once a put)lisher is installed in a hub. It is free to publish advertisements and events. Rg. 3 is a ftow chart showing 
steps performed by a publisher of Fig. 1 during operation of the publisher. Steps involving a call to the event manipula- 
tion routines tiiat are created by compiling the IDL are indicated by an asterisk in the Figure. 

As shown in step 302 of Fig. 3. the publisher first registers itself as a client with the hub to which it is connected. 
45 The publisher next advises the hub of which "advertisement" it will use when publishing. An advertisement represents 
an Intent to publish" and tells the hub what type of event the publisher will be publishing. To advise the hub in step 302. 
the publisher tells the hub the name of an advertisement that has been previously installed in the hub (see Rg. 2), 

In step 304. the publisher waits until it is time to publish an event. Some publishers, such as in the example above, 
publish each event at the time ttiat it occurs. Other publishers wait until a specified time, such as once a day, and publish 
50 all unpublished events at that time. For example, a first publisher may publish an event whenever a human operator 
enters a sales order into the system. A second publisher may publish the same type of event on an houriy basis. Once 
the publisher determines that an event is to be created, it calls (in step 306) one of the event manipulation routines that 
creates a C structure having the proper format for the event to be published. 

In step 308, the publisher calls one of tiie event manipulation routines to publish unpublished events as discussed 
55 below in more detail. In step 310, the publisher calls one of the ev nt manipulation routines to destroy tiie pufc)lished 
event. (In general, in th described embodim nt, whatever entity is responsit)! for allocating an event is also responsi- 
l>le for destroying that event.) 

In step 312. the publisher determines if it should cease execution. If not, control returns to step 304. If so, in step 
31 4, ttie publisher unregisters Itself witii tiie hub and ceases execution. Advertisements are tept in tii hub to indicate 
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that a publisher could execut and s nd those events. This information is needed to build routes to subscribers, as 
desaibed b low. Although not shown in the Figur , other publishers connected to the same hub may operate asynchro- 
nously with the steps of Rg. 3. 

Subscribers subscribe to events of particular event types. Fig. 4 is a flow chart showing steps performed by a sub- 

5 scriber of Fig. 1 during operation of the subscriber. The subscriber first registers itself as a client of the hub. Then for 
each subscription. It registers a "call-back" procedure. 

As shown In step 402, the subscriber next registers itself as a client with the hub to which it is connected. The sub* 
scriber then registers a "subscription" for the event type that it wishes to receive through the hub. (The subscriber can 
look at the hub to see what types of events are advertised.) A subscription specifies a type of event, and can further 

70 specify a lifter" indicating that the subscriber wishes to receive only events of a certain type that also have certain val- 
ues in certain fields. 

in step 404, for each subscrqation, the publisher defines a predetermined "call-back" procedure. The call-back pro- 
cedure will be initiated by the hub whenever the hub determines that the subscriber has received an event of a certain 
type. The format of the callback may be different for each operating system on which the present invention is imple- 

15 mented and the call-back procedure can be practically any procedure that is performed when an event is received. For 
example, in step 406 of Rg. 4, the call-back procedure could print the contents of the event (using one of the event 
manipulation procedures designed to print an event of that type). Because a call-back procedure is defined for each 
subscription, a caJl-back procedure must be defined for each type of event to which the subscriber plans to subscribe. 
In the described embodiment, an event passed into a call-back procedure is destroyed when the call-back procedure 

20 returns. TTius. if the subscriber wants to keep any information of the event, the information should be copied out of the 
event within the call-back procedure. 

The subscriber loops until it is time to cease execution (see step 408). The call-back procedure may be activated 
zero, one, or many times during this loop, as events of the specified type and values are received by the hub. If an event 
sut)scribed to by the subscriber is received, the call-back procedures is executed in step 406. If, in step 408, the sub- 

25 scriber determines that it is time for it to quit, the subscriber optionally unregisters its subscription, unregisters itself with 
the hub, and ceases execution. Subscriptions can also be retained in ttie hub. to receive future events while discon- 
nected. The hub will queue events arriving for the subscriptions. Attiiough not shown in the Rgure. otiier subscribers 
connected to the same hub may periorm steps asynchronously with the steps of Rg. 4. 
The following examples are written in the C programming 

30 language and show example software for a publisher and sut)scriber. 
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* publishx 



#include <nexus.h> 

#include "nxs.ouiput/order_nxs.h" 

int rnainO 
{ 

SalesOrder *event, 
nxsClientID id; 
nxsPublicationID pubjd; 



/* Register the Client and the publication */ 
nxsCreateClient ("order publisher", NULL^NULL, 0, &id); 
nxsRegisterPublication (id, "order.advertisemenf &pubjd); 



/* Create the event */ 

event = nxsCreate_SaIesOrderO; 

event- >customer_name = 'Jim Nexus"; 

event->custonier^address.street = "12345 Anistreet"; 

event- >customer.address.city = "Mountain View**; 

event->customer_address^te = "CA"; 

event- >customer,addressjdp = "95(X)0"; 



/* Publish Event V 

nxsPublish.SalesOrder (id,pubjd,event,0,0); 



/* Cleanup*/ 

nxsDestroy.SalesOrder(event); 



/* Unregister the publication and client */ 
nxsUnregisterPublication (id,pubjd); 
nxsDestFoyClient (id); 
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return (0); 

} 

* subscriber 
V 

#include <nexiis-h> 

#include "nxs,output/order.nxs.h" 

/* Callback function to be called when each event is received */ 
void eventcallback ( 

nxsClientID id, 

nxsSubscriptionlD subjd, 

nsxULong seq^nuni_high, 

nsxULong seq^numjow, 

SalesOrder *the_event, 

void *client data) 

{ 

char *st; 

printfC'Event receivedlXn"); 

St = nxsStringify.SaIesOrder(the,event); 

printfCst); 

free(st); 

} 

int mainCint argc, char **argv) 
{ 

Sales Order *event; 

nxsGient ID id; 

nxsSubscriptionlD subjd; 

/* Register Client and subscription */ 

/* (Only subscribe to specific ZIP axles) */ 

nxsCreateClient ("order subscriber^'^NULL^NULL, 0,&id); 

nxsRegisterSubscription SalesOrder(id, 

"customer address^p == 95000", 

event.calIback,NULL^ubJd); 
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/•Main loop V 
nxsA4ainLoop(id); 

5 

/* Unregister subscription and client */ 
nxsUnregister Subscription (id,subjd); 
nxsDestroyCIient(id); 

10 

retum(0); 

} 

IS 



III. Hubs 

20 Fig. 5 is a block diagram showing details of hub 1 06 of Fig. 1 . Hubs 1 08 and 11 4 of Fig. 1 , and indeed all other hubs 
in the described embodiment, have a similar structure. Hub 106 is connected to remote hubs 108 and 1 14 via network 
120 (or directly] and to zero or more publishers 102 and zero or more subscribers 104. Hub 106 also receives informa- 
tion 530 relating to hub administration, information 532 relating to management of its clients (publishers and subscrib- 
ers), and information 536 relating to system event management. 

25, All input and output to and from hub 1 06 is queued. For example, events received by hub 1 06 from remote hub 1 08 
and from publisher 1 02 are stored in event priority order in respective event queues 502, 504 until hub 1 06 has time to 
process tiiem. As a further example, events to be sent by hub 106 to remote hub 1 1 4 and to subsaiber 104 are stored 
in event priority order in respective event queues 506. 508 in memory until hub 106 has time to send them. HlA>s dis- 
tribute events using a first-in. first-out policy This means that all events having a same priority level will be delivered by 

30 hub 106 in the order that they are accepted from tiie publisher. All events with a higher priority level are delivered earlier 
than waiting events with a lower priority level. The described embodiment guarantees to keep the ordering of like-events 
from a single publisher as tiie events move though tiie system. This is important, for example, in fransaction processing 
where an order of updates must be maintained. Inter-publisher ordering is not guaranteed, since it depends on routing 
and availability issues. 

35 Fig. 5 also shows the following functional blocks inside hub 106: client management block 510. event management 
block 51 2. preprocessor block 514. store block 516. match block 518. and remote administration block 520. Client man- 
agement t>lock 510 deals witii registering and unregistering clients. Event management block 512 deals with managing 
system events, such as receipt of new connections, types, routings, advertisements, and subscriptions. Pre-process 
block 514 performs tasks such as adding envelope information to an event. Store block 516 is a memory of the hub. 

40 Match block 518 adds routing information to events, filters events in a manner described below in connection with event 
routing, and routes events to appropriate other connected hubs. Remote administration block 520 performs system 
administration tasks. 

Fig. 7 is a diagram of data sfructures stored in a memory 690 of hub 1 06 of Fig. 1 that is accessible by all the func- 
tional blocks of Rg. 5. The data structures include a table of installed advertisements 700. a table of registered clients 
45 730. a table of registered publications 760, and a table of registered subscriptions 770. Data is placed in the data sfruc- 
tures of Rg. 7 as the publisher and subscriber perform the various steps of Figs. 2, 3, and 4 as follows. 

Step 202 of Fig. 2 fills enfries of installed advertisements table 700. 

Steps 302 and 402 of Rgs. 3 and 4 fill entries of registered clients table 730. The user name field 734 and user 
password field 736 may have a NULL value to indicate tiiat the cun-ent user ID should be used. Hub name 737 and ter- 
50 ritory name 740 can be set to NULL to indicate use of a default hub and territory Flags 742 include, for example, a 
Boolean value "call-back-on-any-thread." which indicates that event call-backs come on new threads. 

Step 302 of Rg. 3 also fills entries of registered publications table 760. 

Advertisement name 764 is the name of an advertisement that has been installed in the hub. Step 404 of Rg. 4 also 
fills enfries of registered subscriptions table 770. Content filters 774 are discussed below. A name of a callback proce- 
ss dure Is kept locally in tiie subscriber (by th C API). The API finds the callback from tiie subscription ID. A client data 
field, which is also kept by th API, allows information associated with th subscription to be passed back with each 
event callback. The information that is passed back has meaning to the subscribing application. 

The following paragraphs describe tiie varfous types of content filters tiiat can be specified by a subscriber when it 
registers a subsaiption. As shown in th above example. sut)saibers can request that tiie hub filter tiie incoming flow 
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of events and only pass events to the subscribers that match certain crrteria. A filter pref rably is specified as a expres-. 
sion string sent by the subscrib r as a parameter to th routine for registering subscriptions. The expression string syn- 
tax Ibr a content filter in the described embodiment is as ibilcws. (Of course, any appropriate syntax could b used): 



5 





symbol meaning 


types allowed for 






equal to 


all basic types 






not equal to 


all basic types 


10 


> 


greater than 


numeric and string types 




>=, <= 


greater than or equal 


numeric and string types 




and 


logical AND 


expressions or Booleans 


IS 


or 


logical OR 


expressions or Booleans 




not 


logical NOT 


expressions or Booleans 



20 Event attribute names are used to denote which field in the event should be compared. Sub-fields (those inside 
structures) are specified using dot notation. Names can also be enumerated types, as is known to persons familiar with 
the C programming language. Once a content filter has been specified, it is used during event routing as described 
below in connection with Figs. 8-12. Information describing each content filter for a subsarption is stored in field 774 of 
Fig. 7. 

25 Fig. 6(a) is a diagram showing data structures stored in a memory 690 of hub 1 06 of Fig. 5. All hubs contain similar 
data structures. Ihe described implementation uses a distributed objects model, but any appropriate organizational 
structure could be used. Details of the data structures of Rg. 6(a) are listed In Fig. 6(b). Ideally, the data structures of 
Fig. 6(a) describe ail advertisements in the system and indicates a neighbor hub to which the current hub should send 
events of certain types. Rgs. 10 and 12. respectively, describe the steps to populate the data structures of Rg. 6(a) and 

30 to use to the data structures of Fig. 6(a) to route events among the hubs. Rg. 1 1 shows an example of the data struc- 
tures populated with data. 

Hub 106 (the "current hub^ includes data objects representing: each client of the current hub that is a subscriber 
(indicated by "Client" 684 and "S" 695) and each neighboring hub connected to the current hub ("Neighbor A" 696 and 
"Neighbor B" 697). The current hub keeps track of the subscription objects of its neighbor hubs. Subscription objects 

35 "S" 650 represent all subscribers that can be reached through the respective neighbors. Each neighbor object has two 
associated cost values: "mycosT and "theircost". "Mycost" represents a cost of sending information from the cunrent 
hub to the neighbor. "Theircost" represents a cost of sending information from the neighbor to the current hub. Their- 
cost" used to define a route, as described below. The sut)scribing hub will ask the "publishing" hub with the lowest "their- 
cost" to fonward the events. "Mycost" preferably is only used to inform the neighbors of how much it would cost to the 

40 current hub to send information through that link. A "cost" may be figured in a number of ways. For example, a cost may 
represent a financial cost, a cost in units of time, a cost as a measure of convenience, or any other appropriate cost. 

Hub 106 contains a ("RemoteAd") object for each advertisement that has been registered in the system (i.e., for 
each intent to publish, step 202 of Fig. 2). Each RemoteAd object points to one or more "AdSource" objects, each of 
which represents a path between the current hub and the hub on which the publisher of the ad resides. Each AdSource 

45 object stores a cost associated with its path to the original put3lisher of the ad. Thus, the "cost" value for each AdSource 
contains the total cost for sending an event from its source to the neighbor of the cun-ent hub or. alternately, to the cur- 
rent hub. 

Each AdSource object has an associated list of "sink objects." (SinkCa and sinkNb preferably are located in a sin- 
gle list, although not shown that way in the Figure.) Each sink object has an associated list of subscriptions. For exam- 
50 pie. SinkCa has a list 505 of all subscriptions of Client 694 that matched to the advertisement of RemoteAd 510. 
Similarly, SinkNb has a list 515 of all subscriptions of Neighbor B (and of all subscriptions that can be reached through 
Neighbor B) that have matched the advertisement of RemoteAd 510. 

Each neighbor object also has an associated AdSourceRef list that points to AdSources for all paths between a 
publisher and the neighbor. The paths are used for routing system events between hubs, as descra^ed bekTw. 

55 

IV. Event Routing Between Hubs 

Fig. 10 is a flow chart showing details of steps performed by hubs 106, 108, and 1 14 of Fig. 1 to populate the data 
structures of Rg. 6(a). These steps are performed, for example, when ttie network is first initialized. Subsequently, var- 
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ious hubs may Issu "system events" to tell other hubs that chang s have occurred in hub connections, event types, 
advertisements, routings, subscriptions, etc. Appendix A, which is a part of this specification and is herein incorporated 
by referenc , contains a summary of exemplary system ev nts that can be passed betw en hubs in the descrbed 
embodiment. 

5 In Fig. 1 0. th name of the system event of Appendix A that affects a step in the flow chart is shown next to the step. 

In step 1002. hubs send system events to each other to define the physical connections between hubs in the network. 

Each hub creates neighbor objects representing physical connections to its neighbor hubs (see Fig. 6(a)). In step 1004, 

the hubs send system events to each other to define the types of events for which advertisements can be published. 

Each hub makes sure it knows all the events. This step is performed when adding a hub to a territory. In step 1 006, hubs 
10 that are connected to a publisher send system events to other hubs, which are fbnwarded among the hubs, to distribute 

advertisements among the hub. For example, the system event 

NXS_SYS_EVENT_CREATE_NEW_ADVEm"ISEMENT of Appendix A causes the creation of RemoleAd objects in the 

hubs (see Fig. 6(a)). 

In step 1008, hubs that are connected to a publisher send system events to other hubs. The system events are for- 

15 warded among the hubs to determine routes from the publisher's hub to other hubs. (The system event 
NXS_SYS_EVENT_NEW_ROUTES causes the creation of AdSource objects in the hubs (see Rg. 6(a)). To register 
the existence of a route, an initial hub sends a system event to its neighbors, containing an advertisement name/ID. its 
(the publishing hub's) name and territory, and a cost associated with sending an event from the publishing hub to the 
current hub. In the described implementation, the cost is initially set to zero. Each neighbor hub repeats this process. 

20 adding the cost of the connection over which that hub received the event In each hub. if this is the first route to the hub. 
then the local clients are checked for subscription matches (TTils action m^ result in a NEW_SUBSCRIPTION system 
event to the sender of NEW_ROUTES). Each route is considered separately for Ibnwardlng. The route is not fbmvarded 
to the hub from which it was received, to the originating hub, or to a hub that has already seen the event (determined 
from the routing list, as discussed below). The route is only fonwarded to other hubs if it is the first route for the 

25 RemoteAd or if it is the second route and the destination hub is the current route provider. 

In step 1010, hubs connected to a subscriber send system events to other hubs to register a subscription against 
an advertisement known about by the other hubs. (The system event NXS_SYS.EVEIMT_NEW_SUBSCRIPTIONS 
sends subscriptions to other hubs, see Fig. 6(a)). A hub receiving the system event creates a sut>scription object (see 
Fig. 6(a)) and tells the RemoteAd about it. An AdSource having a least-cost path is called the cun-ent AdSource. The 

30 RemoteAd tells the current AdSource, which creates a sink and a subscription object of the Neighbor object (if a sink 
and a subscription object do not exist). The sink then adds a SubscriptionRef entry (e.g., 505. 51 2) for the subscription 
object. If the advertisement was received from another hub, the cun-ent hub fbnflfards a system event for the new sub- 
scription to the neighbor that is a part of the cun-ent least-cost route. 

This fonwarding of subscriptions to other hubs is an important aspect of the present invention. It essentially creates 

35 a chain of subscriptions from a hub of a subscriber back to the hub of the publisher. This chain follows the least-cost 
route between the publisher and the subscnber. 

Fig. 1 1 shows an example of the creation of a chain of subscriptions from a hub of a subscriber to a hub of a pub- 
lisher. Fig. 1 1 shows f ive hubs A. B, C, D. and E. Hub A has a connected publisher R Hub C has a connected subscriber 
S. In the example, each connection has a cost of "1". Thus, for example, there is a route of total cost = 2 between hub 

40 A and C and a route of total cost = 3 between hub A and C. 

Fig. 11 shows the status of the hubs after step 1010 of Rg. 10. Connections, event types, and routes have been 
distributed among the hubs and the RemoteAd, AdSource, Neighbor, and AdSourceRef objects have been aeated in 
each hub. 

In the example, subscriber S registers a subscription on hub C. (Hub C had previously created a subscription object 
45 1 1 02 when S registered itself as a client, indicating that the subscriber S is a client of hub C). Hub C then routes a "new 
subscriplron system event" (a "subscription^ to a neighbor hub that is on a least-cost path to the publisher of the adver- 
tisement for the event. In the example, hub C will route the subscription to hub B, since the cost from hub B to the put)- 
lisher hub A is "1". When hub B receives the subscription, it adds a subscription ot}ject 1104 connected to a neighbor 
object for hub C, indicating that the subscnber can be reached through hub C. 
so Hub B then routes a subscription to a neighbor hub that is on a least-cost path to the publisher of the advertisement 
for the iBvent. In the example, hub B will route the subscription to hub A, since the cost from hub A to itself is "0". When 
hub A receives the sid)Scription, it creates a subscription object 1 1 06 connected to a neigf^r object for hub B, indicat- 
ing that the subscriber can be reached through hub B. Hub A does not route the suljscription further, since it is the orig- 
inating hub for the advertisement that is being subscribed to. 
55 Once th data structures of Fig. 1 1 have been established, an event published by publisher P will be s nt hub-to- 
hub along the path defined by th subscription objects 1 106, 1104, and 1 1 02 until it reaches subscriber S. 

Rg. 12 is a flow chart showing details of st ps performed by th hubs of Rg. 1 to send published events to sub- 
scribers by routing the events tiirough the hubs of the system. The steps of Fig. 12 are performed by 1) a hub tiiat 
receives an event from its connected publisher (step 1202) or 2) a hub tiial receives an event from a n ighboring hub 
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(step 1203). Th steps of Fig. 12 are performed by various hubs as each event is routed through the system. In the fol- 
lowing paragraphs, the hub performing the steps of Rg. 12 is termed the ''current hub." 

If the cunrent hub receives an event from one of its connected publishers (step 1 202). the preprocessor 51 4 of th 
current hub initially adds an "envelope" to th event (step 1204). A format of an event envelope is described below in 
5 connectionwithRg. 8. Preprocessor 514 then det rmines instep 1204 whether the event typ ofth event is registered 
in the hub. If not, the publisher cannot publish the event. If so. in step 1206, the hub places the event in the hub's incom- 
ing event queue for further processing. In the described embodiment, the event queue discards duplicate events (as 
determined by a sequence number or time stamp of the event envelope). 

If the curent hub receives the event from a neight)oring hub (step 1203), the neighboring hub places the event in 
70 the incoming event queue of the current hub. 

In step 1208, filter 518 of the current hub gets the event from the current hub's incoming event queue. Rtter 518 
then increments the time-spent field of the envelope, which indicates an amount of time spent in queue. In step 1210, 
filter 518 adds a routing block to the event. Each hub that routes the event adds another routing block to the event. A 
format of two routing blocks is shown in Rg. 9. 

75 in step 1212. the current hub locates a "current" AdSource object that represents all the subscribers which are 
interested in the event coming from that particular AdSource. This will usually represent a least a cost path between the 
current hub and the subscribers, (note that the described embodiment does not reroute once an AdSource data struc- 
ture is established. The AdSource object is located by either searching all RemoteAds for the current hub (if the event 
came from a publisher attached to the current hub) or from searching the AdSourceRef list for the neighboring hub (if 

20 the event came from a neighboring hub). Steps 1216-1222 send the event to one or more subscribers. Steps 1216- 
1222 are performed for each sink object attached to the AdSourca Thus, steps 1216-1222 are performed for each sub- 
scriber that has asked to receive events of the type being routed. 

If, in step 1216, the time-to-live for the event is less than the time-spent field of the envelope, then the ^nt has 
expired and is not routed further by the current hub (step 1218). Othenwise, in step 1220. filter 518 determines whether 

25 the e^ent has contents that fall within parameters specified by the subscriber. The subscriber specified the content filter 
at the time it subscribed to the event type (see fieW 774 of Rg. 7). For example, a subscriber may have requested to 
receive only those SalesEvents having where the customer lives in Los Angeles. If the event has values in the range 
specified by the subscriber, then the event is sent to the subscriber in step 1222 (either directly or by way of its hub. as 
described below). Each subscriber may have specified a different content filter (or no content filter). For example, a first 

30 subscriber may have specified that it wishes to receive SalesEvents where the customer lives in Los Angeles and a sec- 
ond subscriber may have specified that it wishes to receive SalesEvents where the customer lives in San Frandsca In 
this example, it is possible that the event will match the first subscriber but not the second subscriber. 

In step 1222. filter 518 sends the event to the matching suk)scriber. The subscriber may be a client of the current 
hub. in which case the event is sent directly to the subscriber. Alternately, the subscriber may be connected to a neigh- 

35 boring hub, either directly or indirectly. If a matching subscriber is connected to a neighboring hub, the current hub will 
route the event to the neighboring hub (unless the neighboring hub is the hub originating the event, as determined from 
field 802 of the envelope, see Fig. 8). The current hub also will not route the event to a hub that has already seen the 
event (as determined from the routing blocks attached to the event, see Fig. 9). 

In the described embodiment the current hub only routes the event to a neighboring hub a single time, even if the 

40 neighboring hub has more than one matching subscription. Thus, if subscription object 651 of Fig. 6(a) matches the 
event, the event is fonA^arded to neighboring hub B. If subscription object 652 also matches the event, it is not necessary 
to fonvard the event to the neighboring hub B a second time. When neighboring hub B receives the event, it also will 
perform the steps of Rg. 12 to determine whether any of its client subscribers nnatch the event. 

Fig. 8 shows a format of an envelope data structure of an event. The preprocessor of Fig. 5 adds an envelope to 

45 an event received from its subscriber before the event is published. An envelope is associated with each event and 
includes an origin hub 802, an adname 804. a publisher name 806, a territory name 808, an initial time stamp 810. a 
time to live 812, a priority 814. flags 816, and a time spent fieki 822. Rags 816 are unused in the described emtxxii- 
ment. In an altemate embodiment, the flags may indrcate. e.g., whether an event is "jpersistenT or ''transient." 

Fig. 9 shows an example format of two routing blocks of an event. Each hub adds a routing block to an event that 

50 It routes through itself. The API also includes a get_current_routeJnfo routine that returns information about the actual 
route tiiat an event took to reach a certain subscriber. Routing information is stored by the system as linked list, one 
entry for each hub visited. Each entry includes: an outgoing time stamp for the current hub, a hub name of the cun'ent 
hub, and a territory name of the current hub. The routing information optionally includes a sixty-four bit sequence 
number initially assigned to the event by the publisher. 

55 

V. Territories 

Each tenritory 1 30 and 1 40 of Rg. 1 is a collection of \\\&>s with a common event dictionary. Territories reflect organ- 
izatton. and are not necessarily tied to geography or direct physical connectivity. In tii described embodiment, all hubs 
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within a territory must he fully connected, because advertisement information is not forwarded across tem'tories. Thus, 
ther is always some path, although it may be indirect, between two hubs within a territory without having to leav the 
territory. In a prefen^ed embodiment, hierarchies of territories exist in which lower level tenrHories inherit the event dic- 
tionaries of their parent territory. For example, a corporation may choose to hav a territory for each subsidiary, with all 

5 ofth m understanding certain "corporate ev nts." 

A hub preferably may belong to only one territory. When a client (a publisher or a subscriber) connects to a hub. It 
specifies to which territory or territories it belongs. A client must belong to a territory because the meaning of an event, 
for example a SalesOrder. may be different in different tem'tories. In the described embodiment, each hub has a prede- 
termined default ten-rtory that is used if the application developer does not specify a territory. 

10 In an alternate embodiment, multi-territorial hubs are especially useful for inter-company communication. Two com- 
panies that decide to communicate using the described embodiment of the present invention may set up a joint tenritory, 
agreeing upon some event types and a format to be shared. The hubs connecting the two companies will only fonvard 
events of tinis joint tenritory, since the territory information is kept as part of the advertisement, as described be\ow in 
connection with event routing. 

75 

VI. Database Connectivity 

Fig. 13 is a block diagram of a data base application 1302 incorporated into the network 120 of Rg. 1 . Database 
application 1302. which includes a database library having interlace routines 1304, allows users to access information 
20 in data base 1308. Data base 1308 can be a data base manufactured by. for example. Oracle. Sybase, or Informix. The 
invention can be implemented using any appropriate data base tiiat is capable of operating in conjunction with a trans- 
action monitor. 

Fig. 13 also includes a transaction monitor 1306. Transaction monitor 1306 preferably is the Endna ti'ansaction 
monitor, manufactured by Transarc Corporation. It can also be, for example, the Tuxedo transaction monitor manufac- 

25 tured by Novell. Alternately, any appropriate transaction monitor can be used to inrplement the present invention. A data 
base connecter 1310 having a data base library 1304 connects to network 120 to transmit and receive data from net- 
work 120. Data base connecter 1310 may include software performing hub functions or may connect to a separate hub. 
In Rg. 13, data t>ase application 1302 sends information to data base 1308. Data base application 1302 also requests 
information from data base 1308 and displays that information in human readable form. 

30 Data base connector 1310 can he a publisher, a subscriber, or both. If data base connector 131 0 is a publisher, for 
example, it may publish an event each time a value is changed in data base 1302. It could also, for example, publish 
events at regular time intervals, reflecting the data that has been updated in tiie data base since the last publication. If 
data base 1302 is a subscriber, it stores the information of events it receives in data base 1302. The described embod- 
iment includes a configuration file (not shown) for data base connecter 1310. The configuration file specifies, for exam- 

35 pie. whether the database connection will be a publisher, a sut>scriber, or both. The configuration file also includes, for 
example, a description of events to pii}lish and/or subscribe to. Hie configuration file also specifies irrfbrmation con- 
ceming the layout of data base 1 308. 

Fig. 14 is a flow chart 1400 showing steps performed when the data base is a subsaiber. For example, as events 
are received from network 120. data from the events are added to data base 1 302. Flow chart 1400 assumes that data 

40 base connector 1310 has already registered itself and its subscription(s), as described above. When an event is 
received by data base connector 1 310 in step 1 402. the data base connector maps and stores the data in tiie event into 
data base 1306. The data is not "committed*' to the data base until the data has been completely stored in the data 
base. "Commitment" means that the data is actually entered in the data base. Until the changes to the data is commit- 
ted, they are kept in a temporary storage location. Thus, uncommitted data base can be "rolled back" and the data 

45 transaction cancelled at any time up until the "commit" operation is performed. During a "roll back" tiie changes in tiie 
data in the temporary storage are discarded and the data base is retained in its state before tiie changes were made. 
Under certain circumstances data base connector 1310 will not issue a "commit" command until a certain event is 
received. 

Fig. 15 is a flow chart 1500 showing steps performed when the data base is a publisher. For example, as a human 
50 user adds, deletes and modifies data in the data base 1 302. data connector 1310 sends periodic events to network 1 20. 
In step 1 502, the transaction monitor 1 306 is informed that data base connector 1 31 0 is a "node." The exact manner in 
which this step is performed will vary, depending on tiie manufactiffer of the transaction monitor 1306. but the step gen- 
erally is well-known to persons of ordinary skill in tiiat art. In step 1504. the data base connector 1310 registers itself 
and its advertisement(s), as described above. 
55 Steps 1506-1512 show steps performed, e.g., as the user makes changes to data base 1308. When a data base 
transaction begins in step 1506, data bas 1308 informs transaction monitor tiiat a transaction has begun, using, e.g., 
X/Op n's XA protocol. Transaction monitor 1306 informs data base connector 1310 that a transaction is occum'ng, and 
data base connector 1310 notes th transaction. In step 1 508, changes are made to tiie data base by th user, but tiie 
user has not committed the changes). 
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If, in step 1507. the user (or software making changes) indicat s that the transaction should commit, this fact is 
communicated to transaction monitor 1306 in step 1510. Transaction monitor 1306 informs data t^se connector 1310, 
which pulls the committed data from data base 1308 and put)lishes an event including the committed data. Events ar 
published as shown in Fig. 12. If, in step 1512 the user (or softwar making changes) indicates that the transaction 
should roll back, this fact is communicated to transaction monitor 1306. Transaction monitor 1306 informs data base 
connector 1310, which Ibrgets" about the changes of step 1506 and does not publish an event. Thus, the described 
embodiment takes into account the commitment and roll back operations common to commercial data base operation. 

In an alternate embodiment, where the data base product 1302 used does not include a transaction monitor, data 
base connector 1310 can act as a transaction monitor when connecting with data base 1308. Data base connector 
1310 still acts as a publisher and/or subscriber In this configuration. Data base 1308 thinks that it is connected to a 
transaction monitor, when It is really connected to data base connector 1310. 

VII. Summary 

In summary, a preferred embodiment of the present invention includes a plurality of "publisher" entities, who publish 
infomiation, and a plurality of "subscriber" entities, who request and use the information. Publishers and subscn'bers 
are connected to each other through a network. Hie network is a "store and fbnward" network whose routing is "content- 
based." 

In the desaibed embodiment of the present invention, the basic quanta of information is called an "event." Publish- 
ers publish events and subscribers subscribe to events that match criteria defined by the sut)scriber. Publication and 
subscription are performed asynchronously. Publishers and subsaibers do not have direct knowledge of each other. 
The system receives published event from a publisher and routes the event to all appropriate subscribers. Each sub- 
scriber is guaranteed to receive all events published on the system if, and only if, they match the subscription criteria 
specified by the subsaiber. 

The described embodiment of the present invention makes it easy to integrate legacy systems, legacy applications, 
and legacy hardware into the system and attempts to minimize the amount of information that a user must learn to use 
the system. A legacy data base can be added to the networi^ by way of a data base connector, which can be a publisher, 
a subscriber, or both. 

Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice 
of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, 
with a true scope of the invention being Indicated by the following claims. 

APPENDIX A 
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the tppcinacc of being desmjyol (tU IDL opentkns throw OBJECT.NOT.EXIST) 
even ifaough defli-up may canriniie awhile. 

During df5Tnr*^ the hob dan start is kept in a coosissem stale. If the server is 
shotdowa during tbe middle <tf dettrortion. it can pidc up where it left off when die 
senw reactxvases. 

Tbe onler of objea desoniaQ is impanaot Hist die fiher is discooneacd tan the 
inccMiing EventQoeoe and die pi e tJiiaxsso r otqect ia destroyed. The goal is to pcdnce 
the mzmber of calls ioo ibe hob so diey will deacovaie easily. Next d» H mrr Hnh 
otgea is destroyed. Since dKR is ao destroy opoa^ 

oaed (ace NexosdiDbnnameO). Father drwirrinn of the hob oam wak until dieae 
objects are desouyed because diey may have dHeids ns^ 

Affcr COM A objcos are destroyed, Ae remaining Cn-h obje« 
is ddted. HoaUy. de 1b^ is removed £rcm d» OibSenfcrikff^^ 

6.0 The System Events 

Twcnty-threc system events arc oaed to ccmmnnicaie between hubs. They share some 
d die N^*A^ stxuc&Be of tkoonaL events, but are odnwise totally difiBerent and 
praoesaed outside o£ the noonal event code path. 

The system event uiucmxe is defined in iuLlude^ixs^syspackRhh: 

typedef struct mtaSyet—Evn t H e Bri e r ( 

nxatniong lengUu Byte lenqrb of the event 

oxsOIotig aaglc^QUBber; Used to detect bogus evenrs 

nxsOLon? oexus^veesion; Nexus version maaber 

nxsOXong routtSyjoffaet; nxaeventJtoutlagfiitry 

fUKsOLong sye^eveijtype? NXS_SYS_EVQrr_^ 

OXS0LOB9 detloffset; string data 

} nxsSyatemEven tH — rier ; 

Hm vatees for sysjevent.type can be found in transpan/fanb/sysevenLhh. All sysrest 
code is decLsed in (as w*^**^* of Nem^ffnh) and 

defined in sysevestjoc. 

Tbe sysn evem data is a striiv oiiqwsed of ipaoed sepiEttB^ 
toiooaare: 

string string of any cfaameaenBpt<s{»D& and <nii> 

/saiE^ a string of any chandeaeacepc^. COST) sncranndBd by "^.0037) 

long a signed 32-4)11 vafaK 

ulong >n """r^ 32-bit vafaie 
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TtwSysMiEvwits 



Objea le&ieKes are tnosfdvl in soingifi^ 

Sysiem events are used for sevenl styles of cocmmmicatioo. During cooDeaioQ 
^^Kiuhmwit system evcacs ire used as peer-to-peer isessagca. Hiese evcsa tre not 
by odxr hnbs. Most ocivr events tSea the state of the tcmory tad mxy be 
forwaitled duougbout tbe teavuxy gnpfa. A few events nuy be sexu from i hob to itself. 

NXS_SYS_EVEMT_CONNBCT_HUB 



/string/ Sending hub name 

/string/ Sending huh territory 

string Sending hub inoqalng Event Quexie :: PuataConsuner 

along Pecttlving hob's oosc 

ulong Sending hub's oost 



This evoit is as a result of I call to M^-nT^A W mm-TTTihA/fTntn-mnnwfffnU J]^ 

«>rw<iTig bab has already created the Neighbor and EveooQueoe for the cnnnectka. Tbe 
receiviiig bnb does likewise wfaen it receives die system eveot. Note diat the seoding 
hob already has die inrnming EveniQiEoe::PasbiCoasnmer of tbe icccxviiig via an 

ti ' ^ yntt ^nt to h ^f^^fp^A^V'^*^"*ffffH^^^^**^*' '"^'** ^'t^' ^^"^^ tf rfw* IS rfi^. fiiTf iiyt ^ ^ f] ^^ ^jop 

tiie receivifig fanb (it is joiomg a eaiiory), dien it needs to get die emtory's shared data 
(event types, eic). System eveats are nsnd lo request this isdfonnatiaa from die Kttfisg 
hob: NXS,SYS.gVENTJtH3UEST..EVEyiTYPES. aod 

ffXSJSYS^^yorrjtBXUESTyJ^W^SaiSEM^tS. if die fanb is afaesSy a 
member o£ the lenitory, it ynrfi its rantps <to ifac t^ttA^* with 
NXS.SYS^EVENT _?iEW ROUTES. The re c eiving ikub ahrays reqoests rooies £ram 
d» SBoder widi NXS.SYS JEVEZn' JIEQUEST JU3IJIBS. If die mnmrTWi cannot 
be cRatoda fo€ f ^ypp4ft tfao ^^'''^'^'y name is wrong, the recexvw aexids a 
NXS.SYS.EVENT.OC»WBCrjMLED. 

IIXS.SYS.EVEKrjC0im8CT.FAILE0 

/string/ Sending hub aaoM 
/string/ Sending Inab c«rxltory 
/string/ Bessoa for oooiMctlon failure 

^^^ 1^ ^vfaen ^ fflTf*^^^^?^ ^Ttti^^^^^^^^^^^ fBleda ^3ess np data s^nictmes^ 

MXSjSYS.EVENT.DGCONNKT.HUB 

/string/ Sending hub nam* (or nalgbbor oaae) 
/string/ Semding hub territory 

Th2saystemevcotcnbeMttoselforioana(bcrfanb.Semtt>9eif asaiesoltoCcall lo 

^I^^^A<4mm-^hAAiiiff ^^wm t'mttmmthth CSSe* tfac filSt aXgHIDBDt IS the lUnB 

q£ (he OQ^jbbor bohv The hob sends s siioilir^fcst to the ncig^ibor ^(OontiioiDg the uose 
of the seafing fanb) and does a ccwtnction shmdowu . This may csnse de foUowug 
system eveoa to be sent; NXS.SYS.^VENTJ^AIL_SUBSaUFnONS. 
NXS3YS JVENT JPELEIEJO UIES, aid 
NXS_SYSJEVENT j:)ELEIE.^VERnSFMENTS. One die cywnnrrinn cfasan-vp 
events are aeoc a NXSJSYSJ^VEST^^HDjyFJSTKEAM b delivered. 
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TiMSysMmEvwns 



Tbe sequeaoe of eveais is the same ca the oeighbor hub recexviiig 
NXS.SY5_EVENT_DISCDNNBCr^HUB. 

NXS.SYS_EVENT_END_OF,STREAy 

/string/ Sending bub naae 
/string/ Sending hi^b territory 

Iu£cuB (he Ust evexit » be sees (XI a oooaecQOO. Qeia 1^ 

NXS_SYS_EVEKr_REQUEST.EVENTTYPeS 

/string/ Sending hub naa» 
/string/ Sending hub territory *- 

Send cvcm types to the sender widi NXS,SYS.EVEOT_^IEW.EVENT^YPE_F1LES. 

iaS.SYS_EVENT_NEW_EVENTnfPe_F!LES 

loag Munber of files F 

long Nunber of types T 

BBpeated F times: 
/string/ .nexus file contents 

/szzxnq/ .ifr file contents 

Repeated r tlams: 
string event type noae 

L ff wf <hr IFR Mptw* fil«i mtn tfag IFR Mid QMBd the given event types. The event 
is fU w u 'de d to aU j^^p **'-'* ^ h^'i^^im capcepc the aeader and nrighhora who have 
alre^ seen the evcflt 

P«S_SYS_B^ENT_roRWARO_EVBirnrPE_nL£ 

xUoag Address of EventTyperile state 

loog NuBber of event types r 

Aepeaced r rises: 
string Event type naae 



Send dg event type fiie and event types id ail rrmrtrri neigfabora. Only sent to self 
when cvcotQfpes areereaiBdorn pdi i B i rt . 

NXSJ5YS.EVENT_REQUEST.ADVER7«EIIBITS 

/string/ Sending bub naae 

/string/ Sending bub territory 

Deiivcf all advcrt bcm e uii lo die bub with a 

NXS_SYS _EVENT^NEW_ADVEKnSEMENTS- 

NXS.SYS.EVENT.NEWJkOVERIlSayCKTS 
long Mtviber of advert Isenents A 



A -3 
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TYMSysMlEvwitS 



Repeated A times: 
/string/ Advertisement aane 
/string/ Event type naae 
long Priority 

string Storage laode; "p" or 'f for persistent or tran- 

sient 

ulong Time to live (seconds) 

/string/ Originating hub name 

/string/ Originating hub territory 

Gcacc RcaooceAdsfar ihe tisisd advemsements. The origtnaring bub is where (be 
advetmemem-wis-cxcstcd. The system event is focwtrded to all fnnnffrard neighbors 
excepted the sender itt^oeigbbocs who h«ve sJieady seen die evenL 

NXS.SYS^EVEWT^CONNECnON.READY 

/string/ Sending hub name 

/string/ Sending hub territory 

The yniting hub is ready to use die rmnrrtim If the receiver is also ready, ii zepiies 
wxdi a NXS.SYS.EVEm'.OONNECriON JIEADY. If ti^ coonecdaa is already 
esubUsfaed Che systtn event is ignared. 

NXS^SYS.EVEMT^FORWARD^AOVERnSayiEKr 
string Adverclsenenc nanm 

Send de named idvertisesiieat to «I1 crinwrri nrighhnra. Only sent to self when 
adverdsgnicJitT axecreaiBd. 

NXSJ^YS.EVEMT.CHANGEja>V5niSEIIEKT 

/st.ring/ Advvrtiseoient name 

/string/ Origloating hub name 

/string/ Originating hub territory 

long Priority 

string Storage mods;, •p* or "t* for persistent or tran- 
sient 

ulong Time to live 

Update die mttrhiiig RemoteAd widi the givea vabes. Hie system event is forvarded 
loaU tJUuun r<1firigh boCTC«eept die seader and hnbadiat have already seen the evenL 

NX5_SYS.EVBniDQ£TE.ADVEin6EI»fTS 

long Number oC Advertisements A 

itopeacecf A times: 
/string/ Advexclsenent name 
/storing/ Originating hub nana 
/arrlng/ Originating hub territory 



A -H 
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Tht SystMH Evtnts 



5 



Dekte tbe assocued RmoceAds md reUied diu souctuies. Seoi by the o rigiiwring 
hub wfaen in advcnisemau is deked. Tbe system event is forwuded lo til coooected 
oeighbon excqx tfae seoder and hubs dut bm alxeady ^ 

10 

NXSJSYS_EVENT.REQUEST_ROUTES 

/atrin?/ Sending hub naxoe 

/strxa?/ Sending hub territory 

Ddivcr aU rouiing infonxmion to widi NXS_SYS^EVENT.NEW.ROUIES. 

MX5,SYS„EVEPfr_NEW_ROUTES 

Himber of routes R 
Repeated Jt times; 
Advertisement name 
Originating hub name 
Originating hub territory 
Cost 

p^irw ^ tfc^ Hn r ^ ^ a rocie from tbe sender to die given advcffisrmrTtts at die givgi 
cosL AdSotMce objects aic ocacd and if dsis is die first rooK to die idveit^^ 
local are rhf^finx^ for sobsoipdan marfin This may resolt in a 

NXS SYS..EVENr_NEW„SUBSCRIFIK)NS to die sender of 
NXSlSYS^EVENrjfEW_ROUrES. EjKdi nue is considered separueiy for 
f uwaiuiug. Hie nune is not fut w at de d to die sendee the origiMiiitg hob, or to a hnb 
dut has already sea die eveoL The njoae is only fiswiided if it is die 
RonoiBAd or it is die aeoood loitte and die destmMka hnb it CKiatt 1^ 
Tie cost field of die forimded evctt is inaemenfled by die cott of die connectiaa o^ 
which ds event was received. 

This system evett may matk the end of connrnifw setDp. If the evcat came fion a 
adgfabor dial is not yet fnOy «nnnfrrd , 
35 NXS_SYS_EVENT^C0NNBCnON_READY is sent to die neighboc 



long 

2Q /string/ 

/string/ 
" /string/ 
long 
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NXSjSYS.EVBfTj:HAMQE_ROUTES 

long MoBber of route changes R 

/string/ Originating hub oasM 

4Q /string/ Originating hub territory 

Rapmsted R ClMs; 
/string/ Adveztlseaant naae 
long Cost 

C3iangB dKoostof areDteLHadtbemaadiingBenioceAdandAdSooPseandi)^^ 
45 oast vataeL Tbe system evert bf Uw anted to afl cnnnrff j rd n ri g hhnre eg^ 

and neighbor wbo have already sem die event 

HXS.SYS.EVENT.DELETE.ROUTES 

long Hianber of routes R 

RapeMCad R times: 
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TTw System Events 



/string/ Advert laemant name 

/strxn?/ Ociginatin? hub oase 
/string/ Originating hub territory 

Delete (be roues (AdSouxce) for the gzvtn ■dvexmcmrnrt (Remoc&Ad). Any 
subsccqitioas which woe fed by that xame axe failed. This may result in 
NXS.SYS.EVENrj:AlL_SUBSCIUPTIONS sent to oeighbon who have 
siibeciq)QaDS regisieml for advemscmeaL Forwanfing of each del e te d route is 
coosidered sepantdy and adty if die Jast louie to the advettiscaieat was deteied. The 
sysKm evem is ixx forwazded to die seeder or the orig^Baimg hob. 

NXS.SYS.EVEfn'J»AIIGEj:ONNECTION 

/string/ Sending hub naae 

/string/ Sending hub territory 

long Delta to sending hub's connection cost 

Update their cost for die connecdaa. 

NXSJSYS.EVENT.NEWSUBSCRIPnONS 

long 

/string/ 
/string/ 
/string/ 
/string/ 
ulong 
ulong 

Regiscr sufasaipoaas from the sender against the given adveitxscmenis. Creaie a 
Sabacxipoaa oa die seodiDg iKighbar and lell die Remold 
leHi die um e ui AdSomce which czeaies a Sink for the NeisJlibar (if ooe does not yet 
exisO. Tlie Sink adds a SobacripdoaSef for ti» Sid3SQE%^^ 

If the advcniscBieDt is fion anothrr fanb. fiocwanl a sysiCA event for the new 
mbacjTpdonio the neigfabor applying the cmmitrooie. 

Hie owner and aifaKzipciai ids ne used to kcaK die snfaacxiptioa wfaea it is canceled 
and to kienniy it wfaea it fails. 

ff these is a £ulnre diying snbaoripdoo rcqpstratsoa, an 
NXS_SYS^EVENT J=AIL_SUBSCRIPTIONS is xetstned to die sendee 



NuBber ot subscriptions 5 
itep«aced 5 tlams: 
Advertiseaent naxoe 
Advertiaenant hub nam 
Adwrtisenent hub territory 
Filter expression 
Owner id in sender 
Subscription id in sender 



Nxs_SY5.a^Qn^jCAiica..suBSCfmnx)NS 

long VUEDber of subscriptions 5 

Repeated 5 times: 
ulong Owner id in sender 

ulong Subscription id in sender 



A 
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Caned Uic listed subscriptioas. This evait can be sem 

all rtfercDces lo the subscripdoQ torn all cantm AdSouxoes. This should ddeie til 
rtfatace to the Subscription by Sink owned SubscripdooRrfs. Tbc cancel is foniraxded 
10 to ail acighboR which could possibly feed the subscripdoo. 

NXS_SYS_EVENT_FAIL_SUBSCRIPnONS 

long msnber of failures S 

/Repeated S clmes: 

.^ong Owner id in receiver 

along Subscription id in receiver 

/scring/ Bub name where failure occurred 

/string/ Territory where failure occurred 

/string/ Failure reason 



IS 
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35 



Remove reference lo tte sabscripdoos £ram AdSouices. The subscripdoo itsdf is not 
xgcoed by the faihire. subsoipdoa was £tam a Deigfab^ 
back to the origisaciiig faiib. 

MXS_SYS_EVEMr_P0RWAR0_SUBSCRIFT10N 

ulong Client id 

ulong Subscription id 

VxKwttd de WW sobscripciaa to neigbbacs which caa feed il Tell aU marhin g 

RemoieAds about de siAsoipikiL RonoieA^ 

czeaies a Sink fcr dK Oiett Of one does luc >ctezisa. The Sink adds a So^^ 

^<x ds Subsoipdcu. Send a NXS^SYS^EVEKrjCW.,SUBSaUFnONS (o dK 

cnneic souxce for each Daa-kxml RanottAd. 

MXSjSYS_EVEin'_DEI£re_EVEmTYPE 
string , Event type naae 

Desooy die event type. Hie syAem event is iiarwardBd to all connfctrd neis^ibon 
eaocept die sender and hnfas that have abeady seen die f 



7.0 Miscellaneous 

40 , — . — 



45 



50 



7.1 Event Content Rfteiing 

The fanb nses d£ same filtenng code and API as tbc Nexns client iitfrrfacr When a 
sQbscripcxGa is legisBefBd. the accooipasying filler eaqxessiaa is lua tfartngh 
nxsCieateHlter to acne a oonient filtcz. Hie fanb is rmirilrri widi a vcssioa ai die 
filtering library wbich allocates fihen from FHeap mscad of malice The mnrnt filter 
is xeconkd in dK Subscripdoa sute. When diere is a pottdtia oiaich betwM 
aoddK snbscripdon. nxsHkef&«nt is caUed 10 check for a match. M empty fi^ 
f t p H ! ^$ ifln T Pf #!wem»- 
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Claims 

1 . A method of connecting a data base to a piA)lisher/subscriber network, so that the data base can publish events to 
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the network, the method comprising the steps, performed by the data processing system, of: 

providing a link so that the data base can communicate with a data base connector computer program by w^ 

of a transaction monitor computer program; 
5 setting up the data bas connector as a publisher hub in the network; 

receiving input, by the data base, from a user that alters data in the data base; 

informing the transaction monitor that the data has been altered; 

receiving input from the user indicating that the altered data should be comnutted; 

informing the transaction monitor that the altered data is committed; and 
10 sending, by the data base connector, in accordance with a message from the transaction monitor that the data 

is committed, a published event to the network in accordance with the altered data. 

2. The method of claim 1 . further including the steps of: 

IS receiving input from the user indicating that the altered data should be roiled back; 

informing the transaction monitor that the altered data is rolled t}ack; and 

refraining, by the data base connector, from sending the altered data to the network in accordance with the roll- 
back 

20 3. A method of connecting a data base to a publisher/subscriber network, so that the data base can subscribe to 
events to the network the method comprising the steps, performed by the data processing system, of: 

providing a link so that a data base connector computer program can communicate with the data base; 
setting up the data base connector as a subscriber hub in the network; 
25 receiving, by the data base connector, an event from the network; 

sending, by the data base connector, data in accoidance with the received event to the data base; and 
committing, by the data base connector, the data in the data t>ase. 

4. The method of claim 1 . further comprising the step of: 

30 

sending the event, by the data base connector, to one of its neighbor hubs, where a data structure in the data 
base connector indicates that the neighbor hub is on the least-cost path to a subscriber for the event. 

5. The method of claim 1 , further comprising the steps of: 
receiving an event by the data base connector; 

determining, by the data base connector, in accordance with a data structure of the data base connector, that 
the data base has subscribed to the event; and 
sending, by the data base connector, the event to the data base. 

6. The method of claim 1 , further comprising the step of: 
receiving an event, by the data base connector; 

determining, by the data base connector, in accordance with a data structure of the data base connector, that 
45 a neightx)r hub is connected either directly or indirectly on the least-cost path to a subscriber for the event; and 

sending, by the data base connector, the event to its neight)or hub, so that the event can be forwarded to the 
sut>scriber. 

7. The method of claim 1 , wherein the sending step includes the step of: 

so 

sending an event, by the data base connector, to one of its neighbor hubs when a data structure in the data 
base connector indicates that the data base subscribes to events having the type of the event 

8. The method of claim 1 , wherein the sending step includes the step of: 

55 

sending an event, by the data base connector, to one of its neight>or hubs when a content filter in a data struc- 
ture of the data base connector indicates that the data bas subscribes to events having values found in th 
event. 
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200 

s 



202 



Define one or more 
events (use OMG IDL) 



Compile the IDL to 
204 stmctures in the C 

programming language 
(including header file 
and code generation 
file) 



206 



Install advertisements 
for event(s) in hub 
connected to the 
application 



FIG. 2 

Installing an Application (Publisher) on 

Hub 
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300 

S 



302 

SI 



Register client and 
register publications 
against a pre-installed 
advertisement (step 
206) with hub 
connected to the 
publisher 



304 




Create the event (fill 
in structure) 



306 



Publish unpublished 
events 



308 



Destroy the published 
events 



310 



Publishing Events 
FIG. 3 




312 



Unregister publication 
and client 



314 
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400 

s 



Register client and its 
402 subscriptions with hub 
connected to this 
subscriber (a 
subscription can include 
a content filter) 



404 



Tell the hub to alert 
subscriber when an 
event occurs (i.e., 
register callback 
procedure for each 
subscription) 



Callback function 



408 




Do something 
with received 
event 



406 




410 



Unregister client and 
subscription 



Subscribing to Events 
FIG. 4 
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The following gives the important data fields of the classes in the diagram 
(of Fig, 6(a)). 

Client: name, id, event queue, event queue pushconsumer. Subscription 
list, publication list 

Neighbor: name, id, event queue, event queue pushconsumer, 
AdSourceRef list. Subscription list, my cost, their cost 

AdSourceRef: pointer to AdSource 

RemoteAd: name eventtype name, priority, storage mode, time to live, 
originating hub, originating territory, AdSource list, current AdSource 

AdSource: Sink list, cost 

Sink: SubscriptionRef list 

SubscriptionRef: pointer to Subscription 

Subscription: eventtype name, filter expression, owner id, subscription id, 
reference count, (for remote subscriptions: neighbor owner id, neighbor 
subscription id, ad name, ad originating hub) 



FIG. 6(b) 
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Installed aclvGrtisem3nt& for this hub 



700 



Advert 
Name 


Event 
Description 


Freq of 
Publication 


Event 
Type 


Priority 


Time To i 
Live 















Registered clients of this hub 
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736 


737 


740 


742 




Application 
Name 


User 
Name 


User 
Password 


Hub 
. Name 


Territory 
Name 


Flags 


Client 
ID 

















730 



760 



Registered publications for this hub 
764 



Client 
ID 


Advert 
Name 


Publication 
ID 









770 



FIG. 7 



Registered subscriptions for this hub 
774 



Client 
ID 


Content Filter 
Info (if any) 


Event 
Type 


Subscription 
ID 
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Origin Hub 



Advertisement Name 



Publisher Name 



Tenitory Name 



Initial Time Stamp 



Time To Live 



Priority 



Flags 



List of Subscriber IDs 



Body of Event 



Time Spent 



FIG. 8 
Envelope Format 
of Event 
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Sequence Number 



Time Stamp 



This Hub's Name 



This Hub's Territory 



Sequence Number 



Time Stamp 



This Hub's Name 



This Hub's Territory 



FIG. 9 
Routing Blocks of an 
Event 
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1002 



Distribute information 
about hub connections 
among hubs 
(Create neighbor 
objects) 



1004 



Distribute event types 
among hubs 



1006 



Distribute 
advertisements among 
hubs 

(Create RemoteAds) 



Connect hub 
Connection failed 
Disconnect hub 
Connection ready 
Change connection 



Request event types 
New event types 
Forward event types 
Delete event types 



Request 
advertisements 
New advertisements 
Forward advertisement 
Change advertisement 
Delete advertisement 



Distribute infomiation 
about routes among 
1008 hubs 

(Create AdSources, 
AdSource Ref List 

entries) 
(Choose a current 
AdSource for each 
RemoteAd (Least cost 
Path)) 



Request routes 
New routes 
Change routes 
Delete routes 



FIG. 10 
Populating 

Data 
Structures 

of Hubs 



1010 



Distribute subscriptions 
among hubs 
(Create sinks) 
Each hub passes 
subscription back 
along least cost path to 
publisher) 



New subscriptions 
Cancel subscriptions 
Fail subscriptions 
Forward subscriptions 
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route 
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1202 



1203 



Receive published 

event from 
publisher attached 
to neighboring hub 



1204 



1206 



1208 



1210 



Receive published 
event from publisher 
attached to this hub 






Preproces 
adds en\ 
event and \ 
this type c 
regisi 


sor of hub 
^elope to 
/erifies that 
)f event is 
tered 







Preprocessor of hub 
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